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Abstract 

Agility,  the  capability  to  successfully  effect,  cope  with,  and/or  exploit  changes  in  circumstances, 
can  be  directly  observed  only  when  this  capability  has  been  manifested.  Increasingly  agility  is 
seen  as  an  essential  system  capability  and  hence  a  requirement.  To  satisfy  a  stated  requirement 
for  agility  we  need  to  be  able  to  answer  two  questions.  “How  can  we  measure  a  system’s  Agility 
IQ?”  and  “What  is  the  requisite  amount  of  Agility  that  is  required?”  This  paper  suggests  a  way 
forward  and  illustrates  it,  in  the  context  of  C2  systems. 


Introduction 

Agility  is  increasingly  being  recognized  as  a  ‘must-have’  capability  for  individuals, 
organizations,  and  the  systems  that  support  them  as  enterprises  are  called  upon  to  successfully 
perform,  if  not  thrive,  in  environments  that  are  increasingly  complex  and  dynamic. 

Commanders  and  managers  at  all  levels  are  faced  not  only  with  the  challenge  of  assuring  that 
their  organizations  perform  under  these  challenging  conditions,  but  must  accomplish  this  in  an 
increasingly  constrained  budget  environment  that  limits  the  resources  that  are  available  to  hedge 
one’s  bets.  Thus,  efficiency  must  be  considered  along  with  effectiveness  and  risk. 

The  concept  of  Agility  and  its  six  enablers,  as  articulated  in  a  number  of  U.S.  Department  of 
Defense  Command  and  Control  Research  Program  (DoD  CCRP)  publications,  provides  a 
conceptual  framework  that  can  be  employed  to  find  an  appropriate  balance  between  and  among 
effectiveness,  efficiency,  and  risk.  This  conceptual  framework  provides  a  rational  basis  for 
improving  an  entity’s  agility1.  Progress  in  designing  and  developing  more  agile  entities  will 
depend  on  our  ability  to  observe  appropriate  behaviors  and  outcomes,  associate  them  with  entity 
characteristics,  and  determine  the  amount  of  agility  required.  This  paper  focuses  on  a  critical 
enterprise  function,  command  and  control.  It  discusses  the  need  to  complement  agility 
assessments  based  upon  observation  of  manifest  agility  with  an  a  scenario  free  assessment 
approach  that  provides  a  measure  of  agility  potential,  an  “Agility  Quotient  (AQ).” 

While  the  development  of  a  model  of  potential  agility  is  outside  its  scope,  this  paper  identifies  a 
number  of  questions  that  could  lead  to  the  identification  of  key  variables  and  relationships  that 
should  be  included  in  a  model  of  Command  and  Control  Agility  Potential  whose  output  would  be 
an  entity’s  C2  AQ. 


1  Entity  is  used  here  to  refer  to  the  'unit'  of  analysis  whether  it  be  an  individual,  a  group  of  individuals,  a  formal 
organization,  a  coalition,  a  process,  a  policy,  or  a  system. 


Defining  Agility 

To  paraphrase  some  common  wisdom,  the  only  thing  certain  about  the  future  is  uncertainly. 
Furthermore,  the  situations  we  face  are  and  will  be  dynamic.  Therefore,  solutions  will  become 
less  effective  over  time  and  will  need  to  be  re-invented.  Plans  will  be,  at  best,  short-lived. 

This  is  because  no  matter  how  much  we  invest  in  information  and  uncertainly  reduction,  a 
significant  amount  of  residual  uncertainty  will  remain.  As  a  result,  we  will  always  need  to  deal 
with  unexpected  and  unanticipated  events  and  circumstances.  Agility  is  the  only  other  way  to 
meet  the  challenges  of  complexity  and  dynamics  because  Agility,  defined  as  the  “capability  to 
successfully  effect,  cope  with,  and  exploit  changes  in  circumstances2 3”  is  not  about  “reducing 
problem  difficult  but  is  a  way  of  dealing  with  complexity  and  uncertainty.”  While  this 
definition  of  Agility  is  widely  used  within  the  C2  Research  community,  different  communities 
define  “Agility”  in  different  ways  and/or  employ  a  variety  of  terms  (e.g.,  robustness,  resilience, 
reliability)  for  this  capability.  However,  despite  their  differences,  different  definitions  of  agility 
converge  on  three  key  ideas4. 

The  first  key  idea  is  that  agility  is  an  appropriate  response  to  the  challenges  posed  by 
complexity  and  dynamics.  Increased  system  complexity  and  dynamics  are  associated  with  a 
reduced  ability  to  predict.  Consequently,  these  challenges  are  characterized  by  a  rise  in  the 
frequency  of  unanticipated  events.  Increased  complexity  is  also  associated  with  exacerbating 
the  adverse  consequences  of  these  events  particularly  as  they  may  trigger  cascades  of  effects  that 
cannot  be  adequately  understood  or  controlled.  This  leads  to  an  increased  probability  of 
catastrophic  failure. 

The  second  key  idea  is  that  agility  is  inseparable  from  success,  that  is,  an  appropriate 
measure  of  agility  must  reflect  outcomes.  Thus,  an  entity  manifests  agility  only  if  and  when  it: 

1)  can  seize  upon  an  opportunity  to  improve  performance,  increase  efficiency  and/or  reduce  risk; 
or,  2)  is  able  to  continue  to  operate  successfully  despite  being  put  under  a  stress  that  would 
otherwise  adversely  impact  its  ability  to  operate  successfully. 

The  third  key  idea  is  that  agility  is  not  a  passive  concept,  but  one  that  includes 
anticipatory  and  proactive  behaviors  in  addition  to  being  able  to  respond  to  challenges. 


Observing  and  Measuring  Agility 

Agility  is  defined  as  a  capability  that  results  in  a  specific  outcome  under  specific  conditions.  The 
specified  outcome  is  success,  where  success  is  defined  either  by  the  entity  itself  or  external  to  the 
entity.  Depending  on  the  nature  of  the  entity,  success  will  be  determined  by  some  combination 
of  performance  or  effectiveness,  costs,  and  risks.  The  condition  specified  is  that  of  change, 
either  in  the  mission  (task),  the  environment,  or  in  the  circumstances  to  include  the  state  of  the 
entity. 


2  NATO  SAS-085  C2  Agility  Report  (2013)  p.  20  http://dodccrp.org/sas-085/sas-085  report  final.pdf 

3  Alberts,  David  S.,  The  Agility  Advance  (2011)  DoD  CCRP  p.61 
http://dodccrp.org/files/agility  advantage/Agility  Advantage  Book.pdf 

4  For  a  fuller  discussion,  see  Dove  and  LaBarge  (2014)  Fundamentals  of  Agile  Systems  Engineering 


While  success  or  a  lack  thereof  can  usually  be  easily  observed,  the  reasons  are  often  less 
apparent.  Clearly  one  can  conceive  of  numerous  reasons  why  an  entity  might  be  successful  in 
spite  of  itself  or  its  capabilities,  to  include  Agility.  This  would  suggest  that  an  observation  of 
success  alone  should  not  be  equated  with  Agility.  First,  there  needs  to  be  a  significant  change 
that  has  occurred,  one  that  can  change  the  outcome.  Thus,  for  an  entity  to  be  said  to  manifest 
Agility,  the  entity:  1)  needs  to  be  agile;  2)  needs  to  maintain  acceptable  performance  or  improve 
performance;  and,  3)  possess  some  agility-related  capability  that  could  account  for  the  outcome. 

The  following  six  agility-related  capabilities  or  the  enablers  of  agility  have  been  identified: 

•  Responsiveness 

•  Versatility 

•  Flexibility 

•  Resilience 

•  Adaptiveness 

•  Innovativeness 

Although  it  is  difficult,  if  not  impossible,  in  real  world  situations  to  establish  a  cause  effect 
relationship  between  a  successful  outcome  and  the  presence  of  these  enablers,  it  is  possible  to 
observe  these  enablers  (or  a  lack  thereof)  in  entity  behaviors  and  employ  a  measure  of  the  degree 
to  which  the  enabler  is  present.  Thus,  manifest  agility  and  its  impacts  can  be  directly  observed 
and  measured,  but  only  when  circumstances  that  require  agility  occur,  only  if  the  entity  in 
question  is  able  to,  as  least  in  part,  appropriately  responds  to  the  challenge  at  hand. 

When  an  entity  does  not  possess  adequate  agility,  this  lack  of  agility  can  also  be  observed.  A 
metric  used  to  measure  entity  agility  can  be  calculated  from  these  observations.  It  can  be  quite 
simple.  For  example,  one  metric  is  the  probability  that  an  entity  manifests  agility  when  required. 
Calculating  this  probability  is  a  three-step  process.  The  first  step  involves  the  construction  of  an 
Endeavor  Space,  a  space  that  includes  the  population  of  missions  and  circumstances.  This 
provides  the  set  of  missions  and  circumstances  that  need  to  be  analyzed  to  determine  if  the  entity 
can  successfully  operate  in  different  parts  of  the  Endeavor  Space.  The  second  step  is  to  project 
whether  or  not  the  entity  can  successfully  operate  in  each  part  of  the  space.5  The  third  step  is  to 
sum  the  outcomes  across  the  Endeavor  Space.  This  provides  an  overall  probability  of  success,  a 
measure  of  potential  agility. 

Success  and  failure  have  costs  associated  with  them.  One  way  to  determine  the  value  of  agility 
is  to  take  into  consideration  the  amount  of  time  an  entity  could  not  acceptably  perform  and  the 
magnitude  of  the  performance  shortfall  as  is  depicted  in  Figure  1 . 


5  A  more  sophisticated  analysis  could  estimate  the  conditional  probability  of  success  (see  Alberts  (2011):  The 
Agility  Advantage  DoD  CCRP  -  section  on  Impact  of  Loss  of  Connectivity,  p.  394-8  ) 
http://dodccrp.org/files/agility  advantage/Agility  Advantage  Book.pdf 
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Figure  1:  Observing  Entity  Performance 

Figure  1:  Observing  Entity  Performance  is  a  graph  that  provides  some  very  useful  information 
about  entity  performance  under  stress  or  in  the  event  of  changed  circumstances.  Specifically, 
Figure  1  provides  an  anatomy  of  a  response  time-line  that,  if  improved,  could  reduce  the  amount 
of  time  the  system  failed  to  perform  within  acceptable  bounds  and/or  decrease  the  amount  of  the 
performance  gap.  Figure  1  shows  us  what  the  impact  to  performance  was  but  not  why.  This 
limits  our  ability  to  understand  what  there  is  about  the  entity  itself  (its  design  and  characteristics, 
its  behaviors,  and  the  performance  of  supporting  systems)  that  may  be  contributing  to  this  result. 
We  cannot,  without  other  information,  forensically  determine  if  or  which  of  the  enablers  or 
inhibitors  of  agility  came  into  play.  If  other  observations  were  made,  as  was  the  case  in  the 
SAS-085  case  studies,6  the  presence  or  absence  of  these  enablers  could  be  determined  and,  in 
cases  when  they  were  presence,  a  successful  outcome  could  be  considered  to  be  a  manifestation 
of  agility. 

Being  able  to  observe  entity  behavior  and  to  note  instances  of  manifest  agility  (or  a  lack  thereof) 
and  measure  the  impacts,  does  not,  in  of  itself,  allow  us  to  adequately  assess  entity  agility.  This 
is  because  if  we  were  to  limit  our  assessments  of  an  entity’s  agility  to  those  instances  when  there 
is  a  requirement  for  agility,  our  measure  of  entity  agility  would  be  biased. 

While  measuring  manifest  agility  by  looking  at  the  proportion  of  times  an  entity  successfully 
performed  under  adversity  can,  if  an  entity  receives  low  marks,  provide  systems  engineers  and 
operators  with  an  indication  of  a  problem  and  thus  be  helpful.  High  marks  should  not  be 
considered  to  be  proof  of  adequate  agility.  This  is  because  the  sample  of  stresses  and  conditions 
considered  is  both  extremely  small  and  not  necessarily  representative  of  future  conditions.  This 

6  SAS-085  Case  Study  methodology  and  results  can  be  found  in  Chapter  7  of  the  Final  Report  and  in  Appendix  B 
http://dodccrp.org/html4/sas-085.html 


is,  of  course,  a  gross  understatement.  The  very  reason  we  need  increased  agility  is  that  past 
performance  is  a  poor  predictor  of  future  performance.  History  and  experience  amply  confirm 
this. 

Clearly  we  need  not  limit  our  assessment  of  agility  by  only  using  observations  of  an  entity  in 
operation.  One  approach  that  is  used  to  augment  real  world  observations  and  thus  improve  our 
ability  to  predict  performance  is  to  put  the  system  or  a  simulation  of  the  system  in  a  controllable, 
instrumented  environment  and  create  possible  futures.  Doing  so  allows  us  to  test  the  system 
under  a  variety  of  scenarios  without  waiting  for  them  to  occur  in  the  real  world.  The  set  of 
scenarios  that  is  used,  plus  those  scenarios  that  are  thought  to  be  ‘lesser  included  cases,’ 
constitute  the  design  or  Endeavor  Space.  Appropriated  formulated,  the  Endeavor  Space  can  be 
used  to  calculate  either  an  absolute  measure  of  agility,  a  probability  of  success,  or  a  relative 
measure  that  simply  compares  two  system  designs  or  instantiations  to  the  same  standard. 

System  engineering  practice  is  focused  upon  creating  a  design  space  that  corresponds  to 
“requisite”  agility. 

Designing  and  testing  an  entity  to  these  standards  is  thought  to  provide  a  better  estimate  of  future 
behavior  (success)  than  simply  using  past  performance.  However,  it  could  be  argued  that  the 
scenario-based  approach  could  actually  result  in  a  less  accurate  prediction.  Whether  using  a  set 
of  selected  scenarios  provides  a  more  accurate  assessment  of  system  agility,  depends  upon  the 
number  and  nature  of  the  scenarios  utilized,  that  is,  the  completeness  of  the  Endeavor  Space. 

The  reason  why  a  scenario-based  approach  is  problematic  has  to  do  with  the  difficulty  of 
developing  a  representative  set  of  scenarios,  one  that  adequately  covers  future  situations.  Some 
designers  tend  to  focus  on  the  ‘most  likely’  situations  and  stresses  while  others  focus  on  the  most 
stressing  circumstances  they  can  think  of.  In  either  case,  it  seems  inevitable  that  the  set  of 
scenarios  employed  will  be  constrained  by  pre-conceived  notions,  group  think,  and  biases. 
Empirical  evidence  supports  this  observation. 

The  take  away  is  not  that  we  should  abandon  a  scenario-based  approach,  but  rather  that  we 
should  be  careful  to  employ  scenarios  in  a  thoughtful  way.  Given  the  limitations  of  the  scenario 
approach,  it  seems  prudent  that  we  should  also  employ  an  alternate  approach  to  estimating  an 
entity’s  potential  agility. 

The  Agility  Quotient  “AQ”:  A  Measure  of  Potential 

Given  the  limitations  of  measures  of  manifest  agility,  the  development  of  a  measure  of  an 
entity’s  AQ  or  potential  agility  is  worth  our  attention.  AQ  can  be  patterned  after  the  Intelligence 
Quotient  (IQ).  IQ  is  a  score  that  is  associated  with  educational  potential,  an  ability  to  learn. 

That  is,  a  high  IQ  score  is  considered  to  be  a  predictor  of  education  success  while  a  low  score 
with  a  lack  of  success.  Thus,  AQ,  as  envisioned  in  this  paper,  seeks  to  be  a  predictor  of  success 
in  the  face  of  complexity  and  dynamics. 

The  IQ  tests  with  which  we  are  familiar  seek  to  measure  cognitive  capabilities  such  as  attention, 
memory,  and  problem  solving  ability.  In  other  words,  they  are  attempts  to  measure  fundamental 
attributes  or  capabilities  of  individuals  that  enable  them  to  comprehend,  acquire  knowledge,  and 
apply  it  in  useful  ways.  Since  their  inception  in  the  early  1900s,  the  developers  of  these  tests 
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recognized  that  intelligence  is  too  encompassing  a  concept  to  be  measured  in  a  scalar  metric  . 
Furthermore,  there  were  a  host  of  factors  besides  genetics  that  could  influence  intelligence  and 
along  with  other  factors  could  bias  test  results.  We  need  to  keep  this  in  mind  as  we  try  to 
develop  AQ  tests  and  explore  ways  to  express  the  results  of  these  tests  quantitatively. 

As  we  develop  ways  of  determining  and  measuring  an  entity’s  AQ,  it  seems  reasonable  to 
initially  build  upon  the  enablers  of  agility  that  have  previously  been  identified  and  to  some  extent 
validated  in  case  studies  and  experiments.  Figure  2:  Enablers  of  Agility  ,  depicts  the  six 
enablers  of  agility  identified  above  in  the  context  of  the  characteristics  that  make  tasks  difficult 
and/or  conditions  that  stress  an  entity.  Responsiveness  is  required  to  accommodate  time 
pressures.  Resilience  is  required  to  recover  from  damage  or  degradation.  Flexibility  is  needed 
when  one  way  of  accomplishing  something  does  not  work.  Versatility  is  needed  when  an  entity 
is  used  for  multiple  purposes.  Innovativeness  is  required  when  existing  ways  and  means  are  not 
adequate  for  the  task  and  circumstances.  Adaptiveness  is  required  when,  to  succeed,  the  entity 
needs  to  change  itself.  The  ability  of  an  entity  to  change  itself  includes  but  is  not  limited  to 
being  able  to  adopt  different  approaches  to  C2  (see  A  Model  of  Potential  C2  Agility7 8 9 10). 


time  pressure 


Figure  2:  Enablers  of  Agility 

The  relationship  between  the  presence  (or  absence)  of  these  enablers  and  an  entity’s  ability  to 
remain  at  an  acceptable  level  of  performance  (or  improve  on  its  performance)  is  nonlinear  and 
could  reasonably  be  expected  to  follow  the  form  of  a  traditional  stimulus-response  curve  for 


7  See  Kendra  Cherry,  History  of  Intelligence  Testing, 
http://psvchologv.about.eom/od/psvchologicaltesting/a/int-history.htm 

8  http://dodccrp.org/sas-085/sas-085  report  final.pdf 

9  Adapted  from  Alberts,  D.S.  and  Hayes,  R.E,  Understanding  Command  and  Control 
http://www.dodccrp.org/files/Alberts  UC2.pdf 

10  Alberts  (2011)  Part  VI  Potential  Agility  pp  451-516 


each  enabler.  For  example,  there  is  a  certain  threshold  amount  of  resilience  before  it  has  any 
impact  on  outcomes  and  there  is  a  limit  to  how  much  flexibility  can  be  employed  productively. 
These  relationships  are  further  complicated  by  the  fact  that  the  enablers  are  not  mutually 
independent.  For  example,  responsiveness  can  be  enhanced  by  resilience.  As  is  the  case  with 
agility  itself,  these  enablers  do  not  provide  boundless  value. 

Since  there  are  costs  associated  with  designing  and  building  agility  enablers  into  an  entity, 
tradeoffs  need  to  be  made  between  and  among  investments  in  these  enablers.  These  tradeoffs 
can  be  informed  by  a  model  of  potential  agility  (variables  that  represent  each  of  these  enablers, 
the  relationships  between  and  among  them,  and  with  entity  agility).  The  output  of  this  model 
would  be  a  measure  of  Entity  AQ,  one  that  is  independent  of  specific  scenarios. 


Model  of  an  Entity’s  Potential  Agility  (AQ  Test) 

A  model  of  an  entity’s  potential  agility  seeks  to  explain  why  an  entity  manifests  agility  when  it 
does  and  also  why  it  fails  to  exhibit  agile  behaviors.  The  development  of  such  a  model  is 
informed  by  an  understanding  of  how  an  entity  behaves  under  stress  and  the  processes  by  which 
an  entity  is  changed  to  adapt  and  evolve.  As  such,  a  model  of  potential  agility  is  not  static  but 
will  be  refined  over  time  as  our  understanding  increases. 

Entities  differ  widely  with  respect  to  their  purposes,  the  environments  in  which  they  operate,  and 
in  the  nature  of  the  components  from  which  they  are  assembled,  the  specific  set  of  variables  that 
must  be  included  in  a  model  of  potential  agility  will  differ  as  well.  Furthermore,  even  for 
entities  that  may  have  similar  challenges  and  characteristics,  the  values  of  the  parameters 
associated  with  the  relationships  between  and  among  the  variables  that  form  a  model  of  potential 
agility  will  differ.  Despite  these  differences,  system  (domain)  specific  models  should  be  derived 
from  a  generic  model  of  potential  agility  based  upon  the  enablers  of  agility  and  the  relationships 
between  and  among  these  enablers.  This  will  help:  facilitate  their  development;  ensure  that  all 
aspects  of  agility  are  considered  in  a  systematic  fashion;  and,  facilitate  cross-pollination  that  can 
serve  to  accelerate  the  model  maturation.  Hence,  domain- specific  models  of  an  entity’s 
potential  agility  are  instantiations  of  a  generic  model. 

Over  time,  entities  (individuals,  organizations,  and  systems)  have  evolved  and  as  a  result  have 
learned  (adapted)  so  that  they  excel  in  dealing  with  a  set  of  known  and  expected  stresses.  The 
means  they  have  found  useful,  along  with  the  enablers  of  agility,  constitute  a  starting  point  for 
the  construction  of  an  entity  specific  model  of  potential  agility.  In  the  remainder  of  this  paper, 
two  examples  are  provided  to  illustrate  how  one  can  develop  a  model  of  potential  agility  that  can 
be  used  to  form  the  basis  of  an  AQ  test. 

A  Model  of  C2  Agility  Potential  (C2  AQ) 

There  are  many  ways  to  accomplish  the  functions  we  associate  with  C2.  These  different  ways  or 
C2  Approaches,  correspond  to  different  regions  in  the  C2  Approach  Space.  The  three 
dimension  C2  Approach  Space  is  depicted  in  Figure  3.  These  dimensions  are  not  independent 


as  how  decision  rights  are  allocated  will  impact  the  patterns  of  interactions  and  both  of  these  will 
in  large  part  determine  how  information  is  distributed. 
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Figure  3:  C2  Approach  Space 

Experience,  case  studies,  and  experiments  have  yielded  many  C2  Agility-related  findings.  These 
findings  form  the  basis  for  the  following  set  of  hypotheses  that  bear  directly  on  the  development 
of  a  model  of  C2  AQ: 


•  there  is  no  ‘one  size  fits  all’  approach  to  C2  that  works  well  for  all  missions  and 
circumstances; 

•  Network-enabled  approaches  to  C2  are  more  agile  then  others; 

•  Balanced  approaches  to  C2  are  more  agile; 

•  The  ‘selected’  approach  to  C2  may  not  be  the  one  that  is  actually  being  implemented; 

•  being  able  to  appropriately  adopt  more  than  one  approach  improves  agility  (C2 
Maneuver);  and, 

•  agile  individuals,  processes,  policies,  and  systems  each,  and  in  combination,  improve 
both  the  agility  of  a  given  C2  approach  and  the  ability  to  appropriately  maneuver  in  the 
C2  Approach  Space. 

To  the  extent  that  these  hypotheses  have  merit,  an  entity’s  C2  Agility  is  a  function  of  the:  1) 
number  of  different  C2  Approaches  that  it  can  adopt;  2)  agility  of  each  of  these  C2 
Approaches;  and,  3)  ability  to  appropriately  maneuver  in  the  C2  Approach  Space.  A  model 
of  Potential  C2  Agility  needs  to  include  these  contributors  to  agility,  the  relationships 


between  and  among  them,  and  the  factors  that  impact  the  extent  to  which  they  contribute  to 
agility. 

The  C2  Agility-related  lessons  learned  highlighted  above  suggest  a  number  of  questions,  the 
answers  to  which  would  provide  some  indication  as  to  an  entity’s  C2  AQ  and  point  to  some 
observables  that  could  be  used  to  construct  a  model  of  C2  Agility  potential  that  can  serve  as 
an  AQ  test.  The  questions  that  follow  (see  Figure  4)  are  but  a  small  sample  of  those  that  are 
suggested  by  these  lessons  learned  as  well  as  other  lessons  learned  and  reported  on  in  the 
NATO  Research  Group  SAS-085’s  Final  Report  on  C2  Agility11. 


Questions:  C2  Agility  Potential 


•  What  is  the  most  network-enabled  approach  that  can  be 
adopted? 

•  How  many  different  approaches  to  C2  can  be  adopted? 

•  How  is  the  approach  to  C2  initially  determined? 

•  Is  the  appropriateness  of  the  C2  Approach  periodically 
assessed? 

•  Is  the  way  C2  is  currently  being  approached  monitored? 

•  Are  there  processes  in  place  to  ensure  that  the  C2  approach  is 
balanced? 

•  Is  the  state  (performance)  of  supporting  systems  monitored? 

•  How  agile  are  individuals,  processes,  and  supporting  systems? 


Figure  4:  Question  re:  C2  Agility  Potential 


A  Model  of  Potential  System  Agility 

C2  Agility  depends  to  a  significant  extent  on  the  agility  of  the  systems  that  support  C2.  More 
agile  systems  are  less  likely  to  impose  constraints  on  an  entity’s  choice  of  C2  Approach. 
Fortunately,  system  agility  is  of  increasing  interest  to  the  system  engineering  community.  There 
is  an  interest  in  improving  both  the  agility  of  the  processes  that  design  and  develop  systems 
(agile  acquisition)  as  well  as  the  agility  of  the  systems  themselves  (agile  systems).  Both  are 
important  to  the  C2  community  as  more  agile  systems  will  improve  C2  Approach  Agility  and 
more  agile  acquisition  will  enable  us  to  field  systems  with  needed  capabilities  more  rapidly  and 
efficiently. 


11  This  report  and  its  appendices  can  be  found  at  http://dodccrp.org/html4/sas-085.html 


Over  the  years,  systems  engineers  have  discovered  a  host  of  techniques  (modularization,  table 
driven  logic,  etc.)  and  associated  standards  have  been  employed  to  reduce  the  time  and  costs 
associated  with  responding  to  new  requirements,  one  aspect  of  system  responsiveness.  Means 
have  also  been  found  to  handle  spikes  in  workload  (e.g.;  spawning  of  new  processes  and 
prioritized  queues)  that  eliminate  or  mitigate  the  adverse  consequences  of  increases  in  workload. 
System  resilience  is  an  area  that  has  received  considerable  attention.  As  a  result  ways  to  deal 
with  outages,  delays,  and  loss  of  functionality  are  being  designed  into  systems. 

A  number  of  systems  engineering  principles  are  thought  to,  if  followed,  produce  more  agile 
systems.  These  principles  are  related  to  reusability,  re-configurability,  and  scalability  .  These 
means  of  enabling  agility,  as  well  as  others  that  may  be  identified,  can  provide  the  basis  for  the 
development  of  agility  ‘markers’,  variables  that  measure  the  degree  to  which  a  means  has  been 
achieved.  These  markers  can  serve  as  indicants  of  potential  agility  and  can  be  integrated  into  an 
agility  value  proposition.  Systematic  experimentation  is  needed  to  validate  these  markers  and 
refine  our  understanding  of  the  agility  value  chain.  The  aim  of  a  model  of  potential  agility  is  to 
integrate  all  of  these  means  and  markers  into  a  value  proposition;  one  that  enables  ‘designers’  of 
organizations  and  systems  (e.g.;  commanders,  managers,  engineers)  to  better  understand  how 
they  can  enhance  an  entity’s  potential  agility  and  to  do  so  efficiently. 

Summary 

This  paper  has  asserted  that  agility  is  an  entity  capability  that  can  no  longer  be  relegated  to  a 
“nice  to  have”  requirement.  It  has  explained  that  an  entity’s  potential  agility  cannot  adequately 
be  ascertained  by  employing  only  scenario-based  approaches  to  the  development  of  requirements 
or  for  testing  the  degree  to  which  an  entity  is  agile.  It  concludes  that  a  conceptual  model  of 
potential  agility,  one  based  upon  an  entity’s  characteristics  and  behaviors  under  stress  is  needed 
and  it  suggests  an  approach  to  the  development  of  such  a  model. 
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Synopsis 


•  Agility  has  moved  from  a  'nice  to  have'  to  a  'must  have' 

•  Progress  depends  upon  our  ability  and  willingness  to  observe 
and  measure 

•  Measuring  the  agility  that  is  manifested  has  its  limitations 

•  Scenario  based  simulations  to  predict  agility  have  their 
limitations 

•  A  measure  of  potential  agility  or  Agility  Quotient  (AQ)  is 
needed  as  well 

•  AQ  is  expected  to  be  a  function  of  the  Enablers  of  Agility 
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Agility  -  Ideas  in  Common 


•  Definitions  and  terms  differ  across  communities 

•  Agility  is  a  necessary  response  to  the  challenges  posed  by 
complexity  and  dynamics  of  the  system,  the  environment,  and 
the  interactions  between  them 

•  Agility  is  about  success,  maintaining  or  improving 
performance  in  the  face  of  stresses  and  in  circumstances 

•  Agility  has  passive,  reactive,  and  pro-active  aspects 
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Manifest  Agility 


•  Manifest  Agility  can  be  directly  observed,  but  only  when 
circumstances  require  it  and  only  if  a  system  responds 
appropriately. 

•  A  lack  of  manifest  agility  can  also  be  directly  observed 
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Source:  Alberts,  D.S.  ,The  Agility  Advantage  CCRP  Publications  2011 
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Measuring  Agility 


•  While  one  can  directly  observe  and  measure  the  agility  an  entity 
manifests  or  fails  to  manifests,  one  cannot  assess  the  agility  that 
an  entity  is  capable  of  using  only  these  data  points. 

—  Very  limited  sample  of  potential  stresses  and  changes  in  circumstance 

—  History  is  not  an  accurate  predictor 

•  Simulations  can  add  to  our  understanding  but  also  have  their 
limitations 

—  Lack  of  fidelity 

—  Biases  in  selecting  scenarios  /  stresses 

•  Takeaways 

—  Employ  scenarios  thoughtfully  -  avoid  reliance  on  most  likely 

—  Need  to  augment  with  a  measure  that  does  not  rely  on  scenarios 
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Agility  Quotient  (AQ) 


•  AQ  is  a  measure  of  Potential  Agility  based  upon  an  entity's 
'design'  and  its  agility-related  characteristics 

•  AQ  is  meant  to  complement  measures  that  are  based  upon 

-  actual  experiences 

-  scenario-based  approaches  that  'predict'  expected 
conditions 
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Enablers  of  Agility 


time  pressure 
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Technical  Systems  AQ. 


smart  queues  ways  and  means 


agent-driven  processing 
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Re-cap 


•  Agility  is  an  essential  system's  capability 

•  Improving  Agility  requires  observation  and  measurement 
of  agile  behaviors  and  their  enablers 

•  Measuring  the  agility  that  is  manifested  is  not  enough 

•  Scenario  based  simulations  also  have  their  limitations 

•  We  need  to  be  able  to  estimate  Potential  Agility  (AQ) 

•  A  model  of  AQ  can  be  built  based  upon  the  Enablers  of 
Agility  and  the  ways  and  means  these  enablers  can  be 
actuated 


